1. Field of the Invention
The present invention relates to the field of multicast transmission and more particularly the use of tunneling.
2. Description of the Related Art
Many emerging Internet applications transmit data one-to-many or many-to-many, where one or multiple sources are sending to multiple recipients. Examples of these applications include corporate messaging applications for disseminating a message to multiple employees, stock applications for continually sending stock prices to brokers, and video and audio conferencing applications for remote meetings and telecommuting. One-to-many and many-to-many transmission can be efficiently implemented using the Internet Protocol (IP) Multicast transmission scheme in which sources send a single copy of a message to a group of multiple recipients. Multicast transmission is more efficient than requiring the source to send an individual copy of a message to each recipient (referred to as unicast transmission). In unicast transmission, the number of recipients is limited by the bandwidth available to the source. Multicast transmission is also more efficient than having a source broadcast one copy of the message to all nodes on the network (referred to as broadcast transmission), because many nodes may not want the message, and because broadcasts are often limited to a single sub-network.
In multicast transmission, recipients join a particular multicast session group and traffic is delivered to all members of that group by the network infrastructure. The source does not need to maintain a list of recipients. Ideally, only one copy of a multicast message passes over any link in the network, and copies of the message are made only where paths diverge at a router.
Service provider backbones often use tunneling to make multicast transmission workable and scalable over Virtual Private Networks (VPNs). A VPN includes a number of sites that have IP connectivity over a common backbone. One important feature of a VPN, in particular a MPLS VPN, is that the VPN doesn't require these sites be owned and managed by the same enterprise. Likewise, there is no restriction on the autonomy of the backbone. The service provider backbone can be operated by a single service provider or made up of several interconnecting networks independently managed by different providers. Tunneling typically involves encapsulating multicast datagrams in a standard unicast datagram and transmitting the encapsulated multicast datagram (referred to as a multicast VPN “MVPN” packet), between provider edge routers. Using unicast tunnels does not provide a scalable solution because the unicast tunnels have to be built between customer edge (CE) routers in a full mesh. A VPN with 100 sites would require 99 tunnels on every CE router.
An alternate method builds multipoint tunnels where the destination address of the tunnel datagram is a multicast address. The multicast multipoint tunnels encapsulate MVPN multicast packets. Tunneling makes multicast transmission scalable by reducing the number of multicast routing states required in provider routers. However, when MVPN packets are forwarded using a multicast multipoint tunnel to other provider edge routers, every router connected to that tunnel receives a copy of the MVPN packet, even though there may not be any interested recipients behind that provider edge router. The provider edge router that is not interested in the MVPN packets has to process and drop the packets, which wastes processing resources and bandwidth. Because a tunnel does not have any knowledge of the packets the tunnel is forwarding, there is no way to prune the multicast distribution tree if a provider edge is not interested in the content. The provider edge gets flooded with unwanted packets that must be discarded.
Using multicast multipoint tunneling across VPNs reduces the number of multicast routing states in provider routers, but increases the usage of bandwidth and the amount of processing required of provider edge routers. As multicast applications become more common and applications transmit larger amounts of data, a scalable solution balancing the number of multicast routing states and the amount of bandwidth used is needed.